Style-Based Re nement for Software Architecture

A question that frequently arises for architectural design is \When can I implement a design in style S1 using a design in style S2?" In this paper I propose a technique for structuring a solution to this kind of problem using the idea of substyles. This technique leads to a two-step process in which rst, useful subsets of a family of architectures are identied, and second, re nement rules speci c to these subsets are established. I will argue that this technique, in combination with an unconventional interpretation of re nement, clari es how engineers actually carry out architectural renement and provides a formal framework for establishing the correctness of those methods. 1 The importance of style-based re nement A key issue for architectural design is to understand when a system characterized in one style can be substituted for one described in another. That is, when can I use an instance of style S1 in place of a system already described in style S2? This problem arises in a number of contexts: Representing the internal structure of an architectural component (or connector): Often the elements of an architectural description are implemented internally by another, more detailed architecture. In some cases the boundary of one element serves to aggregate and encapsulate certain parts of a complex description (i.e., S1 = S2). In this case, simple name mappings between the internal representation and the external may su ce. But more generally, the internal representation may involve a change in architectural style. For example, I might have a component of a pipelter architecture that is internally constructed using componentry based on procedure-call. Recasting an architectural description in a new style: Often a system that is most naturally represented in one style must be implemented using the facilities that are best described in another style. In this case, a complete architectural description (not just individual elements) must be represented in a new way. For example, I might represent an event-based design in an object-oriented one, in order to pave the way for more direct implementation using an object-oriented language. Applying tools developed for one style to a system written in another one: Architectural analysis tools are often written for systems that t within a given style. For example, a timing analyzer may apply only to pipelter systems, while a transaction throughput analyzer might apply only to a certain class of repository-oriented systems. However, sometimes we have a system that is characterized by a style that has enough commonality with another that it makes sense to apply tools developed for the second style. As a simple example, I should be able to apply a pipelter timing analyzer to an instance of a pipeline style (i.e., a linear sequence of lters). For any speci c instance of the problem it is possible to cast the solution in terms of traditional re nement. That is, system X2 can be used in place of X1 if we can nd a suitable \abstraction map" from X2 to X1. This is essentially the approach taken by Rapide [3]. The events of one system are mapped to the events of the other system, and then tools check that the resulting behavior of the concrete system is consistent with that of the abstract system. (I will reexamine this simplistic notion of re nement later.) However, architecture provides an opportunity to do much more. Instead of comparing architectural instances we develop a set of rules between architectural styles. We then prove that two systems (in the respective styles) that are related by the re nement rules represent a valid re nement relationship. For example, we might determine that any eventbased system can be implemented as an object-oriented system if we transform each component so that it calls an event dispatcher, and we transform the event connectors to a dispatcher-mediated, broadcast connector. This approach to re nement can be called style-based re nement. Naturally, techniques that apply at the level of styles are much more powerful than techniques that apply to instances. This is because the demonstration can be performed once for the styles and then reused many times for instances of those styles. Moreover, it permits veri cation to be done by specialists in style de nition, while allowing regular system designers to simply use the results with con dence that they will be correct. Finally, it makes explicit the rules of thumb that engineers develop to implement one kind of system abstraction in terms of another. 2 The problem of style-based re nement The problem, however, is that style-based re nement is much more di cult to establish. To have a set of valid rules one must show that every instance of one style has a valid re nement in the other. Since the demonstration of substitutability must range over a possibly in nite collection of systems, it involves more general proof techniques. One such technique, proposed by Moriconi and his associates, is to use a set of compositional re nement patterns [4]. The patterns determine local transformations for parts of an architectural description. The patterns are constructed in such a way that the local transformations compose and, if applied systematically to a system, will result in the construction of a system in another style. This approach, when it works, is a good idea. However, in general, it may be di cult to nd transformation rules that apply to all system instances in a given style. Consider, for example the problem of implementing pipelter systems using a shared variable style. (That is, pipe reads/writes are accomplished by reading and writing to shared variables). In the presence of cycles, a lter that needs to read more than one value before producing its result can cause the shared variable system to deadlock. Thus not all pipelter systems can be implemented by the simple rule of replacing pipes with procedure calls to shared variables. On the other hand, clearly some pipelter systems can. In the remainder of this paper I sketch an alternative (but complementary) technique that advocates the principled use of substyles for dealing these issues of re nement. The basic idea is to identify subsets of the systems in a given style that are amenable to specialized treatment. This approach improves our capabilities for de ning style-based re nement, because we are freed from the requirement of carrying it out on all systems within a given style. I argue that this not only provides a solid formal basis for carrying out style-based re nement, but corresponds to what engineers actually do (informally) when then they implement architectural designs. I then elaborate on both these points by enumerating the formal and methodological implications. 3 The use of substyles in re nement In practice, systems builders often exploit idiosyncracies of a given system to provide e cient implementations. For example, a program that uses sets, but requires only sets with small numbers of binary values, may use a bit vector. For architectures the situation is similar. If I have a system that I know is constructed as a linear sequence of lters, I can produce a functional implementation that simply composes the transformations of the pipeline into a single, more e cient function. Thus, as long as one is concerned with re nement of architectural instances, it is possible to demonstrate that a specialized re nement technique is appropriate. But when we move to styles, this is no longer possible. Since we cannot exploit the particular idiosyncracies of a design we can't in general take advantage of these special cases and contexts of use. Thus there is an apparent dilemna: Style-based re nement is more powerful and generally useful, but can be applied much less e ectively. I would argue, however, that a solution can be found by applying at the style level the same technique used for instance re nement: we exploit the idiosyncracies of a subset of the systems in a style to produce specialized re nement rules for that subset. This involves a two step process. First, suitable substyles of the style are identi ed. A substyle is characterized as a collection of additional constraints (beyond those imposed by the style). Second for each substyle, we use the additional constraints to de ne specialized re nements. To take a simple example, we might de ne a \pipeline" as a substyle of pipelter, by adding the constraint that the topology must be linear. For this substyle, we can then dene a simple re nement rule from that substyle into a functional composition style (i.e., stream transformations are simply composed). A more complex substyle of pipelter would be, acyclic, \balanced", 1-in-1-out systems. In these systems each lter computes one output value for each input value that it consumes, and the overall graph is acyclic. For this substyle, we can de ne a simple re nement rule into a shared variable style. (For an example of a formal proof of a similar result, see [1].) Formally, this approach can be characterized by two functions, as illustrated in Figure 1. The rst is a partial projection function that determines whether a given system (labelled Style 1), is a member of a specialized substyle (labelled Style 1a). The second function determines the re nement relationship between members of the abstract (sub)style and members of concrete style (labelled Style 2). Formally this is characterized as an abstraction function, since there may be many concrete systems that can be used to represent the abstract system. Note, however, that both functions are surjective: that is, all elements of the substyle are handled. In terms of engineering practice, we observe that this general approach is what engineers typically do. When presented with a system that must be implemented in a di erent style, the engineer will typically look for characteristics of the proposed system that enable the use of certain standard techniques of implementation. The de nition of substyles simply makes explicit (formally) which constraints must exist exist in order to use those techniques safely. Thus the approach of de ning useful substyles provides a home for capturing the understanding of experienced designers. 4 What is re nement, anyway? Until now, we have been vague about what re nement actually means. However, the de nition of re nement is a critical issue, since it determines the correctness criteria for a set of re nement rules (or equivalently, the abstraction map). The \classical" approach is to use the notion of behavioral substitutability. That is, the concrete representation should not produce any externally-observable behavior that the abstract representation could not have produced. This is essentially the criterion used by Rapide. It is also the criterion used by CSP[2]. But, as Moriconi and others have argued [4], behavioral substitutability may not be strong enough. In general, there may be properties other than computational equivalence that we wish to preserve in the concrete representation. Moriconi proposes that for architectures it is su cient to impose a requirement of \conservative extension". Formally The function may include renamings, such as \ lter" to \stage".